Creating Eecient Fail-stop Cryptographic Protocols

Fail-stop cryptographic protocols are characterized by the property that they terminate when an active attack is detected, rather than releasing information valuable to the attacker. Since such a construction forces attacks (other than denial-of-service) to be passive, the protocol designer's concerns can be restricted to passive attacks and malicious insiders. A signi cant advantage of such protocols is that by stopping and not attempting to recover, proofs about protocol behavior and security properties are greatly simpli ed. This paper presents a generic method of converting any existing (cryptographic) protocol into a fail-stop one, or designing new protocols to be fail-stop. Our technique uses cryptographic hashes to validate sequences of messages by re ecting message dependencies in the hash values. An informal proof of correctness is given. We apply it to an early version of Netscape's Secure Socket Layer (SSL) cryptographic protocol. We also suggest a possible application to TCP streams as a high-performance alternative to the per-packet authentication of IPSEC. The modi ed protocols require small increases in message size and the number of cryptographic operations relative to the initial non-fail-stop protocols. Copyright c 1996, Angelos D. Keromytis and Jonathan M. Smith. Permission is granted to redistribute this document in electronic or paper form, provided that this copyright notice is retained. Authors' email addresses are [email protected] and [email protected]. This research was supported by DARPA under contract #N66001-96C-852. 1 Fail-stop protocols Cryptographic protocols are widely used in many advanced applications, such as electronic banking, networked software distribution, and wireless personal communications systems. Due to the complexity of conditions they may encounter, careful reasoning and formal means such as proofs are used to validate the design of a cryptographic protocol. Such validation is easier if the set of threat conditions is reduced. If this reduction is via assumptions which ignore reality, the validation becomes worthless when the assumptions are falsi ed. Techniques resulting in the construction of protocols which by design reduce the complexity of threat conditions are thus extremely attractive. One such idea is a fail-stop cryptographic protocol, recently introduced by Gong and Syverson [FS]: A protocol is fail-stop if any attack interfering with a message sent in one step will cause all causally-after messages in the next step or later not to be sent. As Gong and Syverson show, fail-stop protocols possess a very useful security property, namely: active attacks cannot cause the release of secrets within the run of a fail-stop protocol The fail-stop property lets a protocol designer restrict his or her concerns to passive (eavesdropping) attacks, a signi cant reduction in the class of threats to the protocol's security. There is, of course, no free lunch: the protocol must terminate when active attacks occur, rather than attempting to continue. However, when embedded in a larger system, this termination can be handled by higher-level detection and resolution mechanisms. We believe that reliable termination is greatly preferred to unknown and insecure behavior in the face of active attacks on security. 1.1 Specifying fail-stop behavior Syverson and Gong state the following speci cations for a fail-stop protocol: 1. The content of each message has a header containing the identity of its sender, the identity of its intended recipient, the protocol identi er and its version number, a message sequence number, and a freshness identi er. 2. Each message is encrypted under the key shared between its sender and intended recipient. 3. An honest process follows the protocol and ignores all unexpected messages. 4. A process halts any protocol run in which an expected message does not arrive within a speci ed timeout period. The above speci cations assume that the two communicating parties share a secret encryption key used with a symmetric key cryptosystem (such as DES [FIPS46]). The freshness identi er can be a nonce issued by the intended recipient or a time stamp (if the clocks are assumed to be securely and reliably synchronized| but see [LG92]). 1.2 Outline of this paper Section 2 presents our method for chaining the messages of a protocol run. This makes the messages sequenced and non-reusable outside the context of this protocol run, thereby making message tampering and replay attacks impossible [PS]. Section 3 gives a detailed example of the methods applied to the SSL cryptographic protocol. Section 4 proposes applications to a large class of protocols, those which provide reliable message streams. Section 5 makes some observations about the method, and addresses some potential criticisms. Section 6 concludes the paper and summarizes its contributions.